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0 Creating and controlling lighting designs. 



© Disclosed is a modelling and control system for creating lighting designs off-line and for controlling on-line 
the operation of the actual lighting systems producing those designs. Using a programmable computer, the 
modelling system prompts Inputs by the designer/programmer describing model objects and their parameters 
including stage dimensions, set pieces and their locations, performers and their positions, trusses, lamps and 
their parameters such as color, focus, intensity, beam edge, and the relations among the objects. The sytem 
computes the resutant lighting scenes, organized as cues and arranged and formatted to be compatible with 
actual lighting controller usage. The system displays the model environment in such a way as to facilitate the 
modelling operation and its results. It also also generates a variety of spreadsheets for use by the designer. 
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limited. Consequently, to be truly effective and affordable, the modeling must involve uncomplicated, 
preferably intuitive tasks; and it must invoke fairly simple instrumentalities which nevertheless are suffi* 
ciently revealing or suggestive to enable the designer to visualize the real effect and the states or values of 
the variables contributing to that effect. Current systems are deficient in these respects. 
5 Ideally, the system should also simulate the console controls to avoid the need for mastering new 
control/effect relationship. 

It is accordingly an object of the invention to provide an improved ijghting design instrument which 
permits off-line creation of lighting designs and thereby reduces dependence on the performers, the theatre 
and the lighting equipment. 

to A further object of the invention is to provide an instrument which facilitates the lighting designer's 
visualization of various lighting effects without the need to access the actual lighting equipment. 

Still another object of the invention is to present the user with both schematic and realistic graphical 
displays, thereby allowing the user to eliminate representations of model data which are not of interest and 
permitting the use of low resolution or monochrome displays. 
'5 It is yet another object of the invention to provide off-line programming of lighting productions which 

can be simply and rapidly integrated into the actual lighting equipment system. 

Yet another object of the invention is to provide an instrument for off-line creation of lighting productions 
which can be implemented with a relatively inexpensive computer system and which nevertheless com- 
putes and displays revealing simulations of lighting parameters. 
20 A still further object of the invention is to provide an off-line lighting show design tool the output of 
which can be used to directly control lighting instruments. It is also an object to provide the output in a form 
permitting real time rendering of the lighting design. 

Another object is to duplicate the control functions of the automated lighting console, allowing the 
modelling system to be used to directly control the luminaires in a situation where the effects of operator 
25 actions on the luminaires cannot be directly observed by the operator either from the modelling system or 
console location. 

Still another object of the invention is to provide an off-line lighting design programming tool which can 
symbolize and simulate complex lighting relationships in a simple, uncluttered and revealing manner and 
without excessive response time. 
30 It is also an object of the invention to provide such a programming instrument wherein there is 

produced a variety of displays suited to the varying needs of the designer. 

Another object of the invention is to provide an off-line modelling system for a lighting set in which 
prompts for the user bear an analogous relationship to actual console configurations. 

Yet another object of the invention is to provide an off-line modelling instrument for lighting productions 
35 which offers the user a choice of methods in specifying model data, and in which menus and dialog boxes 
facilitate use of the Instrument. By emt^edding in the system terms and notations familiar to the lighting 
designer, and producing the customary actions associated with them, the user is able to communicate with 
the system using the same vocabulary and achieving the same results as would be the case with a human 
rather than machine lighting designer assistant. 
40 Further objects of the invention are to provide an off-line modelling system for lighting designs in which 
a mathematically correct three dimensional model of the performers, the set. the trussing and the luminaires 
of the show is computed and displayed: in which pan and tilt values can be calculated in terms off target 
position; in which model elements are automatically adjusted when related elements are changed, and in 
which updating and revising is simply accomplished. 

45 

SUMMARY OF THE INVENTION 

In the implementation of the invention, a system is provided for modelling a lighting production 
including the characteristics of the production site and the lighting scenes produced by the lighting console 
and the lighting instruments without requiring access to the site and instruments. The system utilizes a 
computer having data entry means, a processor, storage means, a monitor and a graphics generating 
program. The modelling system further includes: 
(1) means for receiving data: 

(a) describing relevant parameters of the lighting site including lighting targets: 
<b) identifying the selection of the lighting instruments to be operational in the production of the 
lighting designs; 

(c) describing the location of the selected lighting instruments; 

(d) describing values of the lighting parameters associated with each of said selected lighting 
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Figures 4a and 4b are views of model data displayed in a spreadsheet format; 
Figures 5a and 5b illustrate other spreadsheet formats for the model data; 
Figures 6, 7. and 8 illustrate the monitor screen and various manipulation dialogs; 
Rgure 9 Is a view of the monitor screen showing the tools patette; 
s Figures 10A through IOC are views of the monitor screens showing various object selections; 
Figures 11A through 11C are views of the monitor display illustrating other selection activities; 
Figures 12 and 13 are diagramatic views of a luminaire illustrating the coordinate axes and angle 
specifying conventions; 

Figures 14 through 17 and Figures 18A. 18B and 18C describe processing steps used in computing 
ID various lamp positions; 

Figure 19 shows the monitor display screen with the cue store and recall palette; and 
Figure 20 shows the monitor display with an actual lighting scene simulated thereon. 

DESCRtPTION OF THE PREFERRED EMBODIMENT 

15 

Certain aspects of the invention are illustrated in Figure 1 where a computing system 20 is displayed for 
modelling the lighting production eventually to be produced by the actual lighting system 100. The latter 
includes a lighting console 110 such as the ARTISAN^" or MINI-ARTISAN™ marketed by Vari-Lite, Inc. 
and a network of lamps which may for example be various combinations of the models Vl-2, VL2B. VL3 and 
20 VL4 previously referenced. 

The lighting controller may be of the type associated with the Vari-Lite VL200 series lighting system 
and portions of the controller may also be configured as described in United States Patent No. 4.980,806, 
issued to Taylor and Walsh on December 25. 1990. 

The computing system 20 is a general purpose computer running under the graphic system described 
25 hereinafter. The preferred computer model is a Apple Macintosh II fx. It includes a microprocessor, RAM, 
ROM, storage and interfaces with the user via mouse 28 and keyboard 30. A modem for communication is 
' also provided and data can be printed on the hard copy printer. 

To facilitate an understanding of the implementation of the invention, certain general factors of the 
illustrated embodiments are first described. The design includes a modelling system and a method for 
30 modelling, programming, and simulating the functions of an automated lighting system such as 100 having 
variable multi-parameter lighting features. The modelling system and method may be used to write lighting 
cues in advance. 

Using the general purpose computer 20 embodying the graphics generating system and software the 
programmer/designer can develop a working model of a lighting system configuration and its surrounding 
35 environment. The programmer defines the spatial environment, e.g. the theatre or arena, in which the 
lighting equipment will be used. In addition, the programmer defines each of the elements that comprise the 
lighting system, stage environment and targets to be illuminated. Using the modelling software to generate 
a graphical display of the lighting system on monitor 24. the system is capable of creating and manipulating 
the defined objects. 

40 With the modelling system of the present invention, all that is required to develop the model is 
^ knowledge of the dimensions and characteristics of the arena and stage environments and a determination 
of the number, type, and placement of the lights to be utilized. This can be done in advance without 
entering the arena or hanging any lights. 

Once the programmer has developed the basic model by defining the positional relationship of each of 
45 these elements with respect to other elements in a universal frame of reference, the modelling system 
provides for the graphical creation and manipulation of show objects and their associated attributes in three 
' - dimensions on the two dimensicnat display such as screen 24. 

The programmer defines positional and characteristic information for each element in the model by 
communicating Interactively with the modelling system using the mouse 28, keyboard 30. cursor 34 and 
so other screen objects including icons 35, menus 36 and model objects 37. 

Cue parameter data may be written by identifying the lights to be assigned, their shape and color, and 
the position of the associated targets to be Illuminated. The cue parameter data may include data 
representing other desired beam characteristics. 

After the programmer has obtained the desired lighting effect by defining the beam characteristics and 
55 associating the necessary lights with their corresponding targets, the system can compute, if necessary, the 
required pan and tilt values for each light so that it is focussed on the desired target. The programmer can 
define the pan and tilt values either by specifying absolute values for these parameters (thus, not requiring 
a pan and tilt computation) or he can associate the lights with their targets. When a light is associated with 
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communicated and reflected in the console and vice-versa. 

In the third alternative mode of interaction, the modelling system actually replaces the conventional 
control console in the control of cue set-up. store and recall. All of the functions of the console are then 
performed by the modelling system. 
5 Alternatively, the functions of the modelling system can be performed by the control console itself. In 
the fourth mode of interaction, the modelling system replaces the lights in the actual system, responding to 
the controls of the actual console as the lights would. The effect of the user's manipulation of the console 
controls is reflected in the display of the modelling system. 

10 GRAPHICAL VIEW OF THE MODEL 

The modelling system of the present invention includes a graphical user interface to interact with the 
programmer. In general, the preferred interface follows the guideleines designated in Human Interface 
Guidelines: The Apple Desktop Interface. ISBN 0-201-17753-6 . The interface presents the programmer with 

;5 a graphical view of the model that is a clear, simple, and uncluttered representation of the current state of 
the objects in the model. ^ 

Lighting instruments or other objects can be created, modified and deleted in the graphical view of the 
model. The model objects can be displayed utilizing symbols such as "spheres" for the luminaires, blocks 
for the stage performers, and "rods'* for the light beams and trusses. These tasks are performed by the 

'20 programmer, preferably by means of executing menu-driven commands. These functions will be addressed 
in greater detail below. 

The modelling is carried out with the aid of a programmable general purpose computer such as shown 
in Rgure 1. A preferred model is the Apple Macintosh II fx. Computer 20 houses the usual complement of a 
processor. ROM memory, drives, busses and control circuits and the modelling system. 

25 A typical graphical input device 28 such as a mouse, joystick, tracker ball, or light pen. together with the 
menu system and cursor 34, allows the programmer to interact with computer 20. Mouse 28 is the preferred 
graphical input device for pointing to information on display monitor 24. Alphanumeric keyboard 30 provides 
the usual functions and also serves as an alternative data entry means. 

In the preferred emtx)diment of the present invention, menus are utilized to allow the programmer to 

30 efficiently choose an item to be incorporated or updated in the model, or to alter the operating mode of the 
system. The menus are also utilized to present to the programmer only the legitimate alternatives available, 
thereby precluding invalid choices. The menus also ameliorate the need to remember command names and 
give the programmer an overview of all of the alternatives. 

Fig. 2a shows a typical graphical display of a lighting system on display monitor 24. A "menu bar" 38 

35 lists the names of typical pull-down menus 44 a - g. from which the programmer may select commands as 
shown in Figs. 2a -2g. When the programmer selects a menu to be displayed from the '*menu bar** 38. 
alternative commands are presented for further selection. The selection process and the individual pull- 
down menus 42 a- g are discussed in greater detail below. 

As the programmer builds the graphical model that represents the lighting system and surrounding 

40 environment a corresponding master data base is created and stored in the memory of computer 20. The 
master data base stores the parameters and attributes that define the objects that are represented in the 
model. As the programmer adds an object to the model, a record for that object is created and stored in the 
master data base. As discussed below, each record has a field for each of the attributes of the object that 
need to be defined during the modelling and programming process. 

45 The image that is seen on display 24 as the programmer builds the model through an interactive 
graphics process is stored in the underlying master data base in digital memory as a matrix of values. The 

s screen image is stored in a frame buffer as a pattern of binary numbers representing an array of picture 
elements (pixels). As changes are graphically made on display 24. the records created in the digital 
. memory are modified to represent the current state of the graphical model. 

50 As the programmer models and programs the lighting system, monitor 24 displays a view of the lighting 
system and stage environment and shows the programmer the results of adjustments to the lighting 
parameters- The programmer can observe the effects of changes in color, pan, tilt, beam size. edge, and 
intensity on the overall lighting effect. Other effects, e.g.. gobo selection, are also represented in a similar 
manner. 

55 Fig. 3 illustrates the display on screen 24 of windows 54 a-c. which are plan, front and side elevation 
views respective, of the model. In one preferred embodiment, the display utilizes up to four windows to give 
the programmer the ability to observe the lighting effects from these views, and a perspective view from 
another selected point (not shown). 
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modelling file. As the programmer adds elements to the model, the associated data will be included in the 

various spreadsheet views discussed below. 

A first spreadsheet view, termed a "model window", is shown in Fig. 5a. It provides a view of the model 

objects and their current attributes which allows the programmer to view data that is necessary for the 
s modelling environment, but is not represented in the cue data transferred to the lighting system. For 

example, in order to develop the model it is necessary to know the dimensions of all of the set pieces. 

However, this information is not required to perform, the actual show. The spreadsheet in the "model 

window** can be arranged so that the user-assigned names and model types (lights, set pieces, etc.) appear 

in the row headings, and the names of the attributes of these objects appear in the column headings, as 
to shown in the Figure. 

A second type of spreadsheet called a "luminaire window" is shown in Fig. 5b, This spreadsheet 
presents the programmer with the lighting system data that he is accustomed to programming. Timing data 
is displayed along with flags or indicators indicating to which parameters the timing applies. This 
spreadsheet can be arranged so that the channel numbers or other identificatipn of the tights are placed in 
IS the row headings and the names of the attributes of these lights are placed in the column headings. This 
spreadsheet represents the state of the luminaire objects in the model, and the data presented will change 
as cues are recalled into the lights, as well as when individual lights are manipulated. 

A third type of spreadsheet catted a "cue window" displays the data stored in a selected cue. 
regardless of the state of the luminaire objects in the model. This spreadsheet can be arranged so that the 
20 channel number or other identifier of the lights appears as row headings and the column headings contain 
the names of the attributes of the lights. The cue number and additional data stored with the cue related to 
console functionality are also displayed. The programmer may select whether the attributes of all the lights 
are shown or only those lights that are active in the selected cue. This spreadsheet can be switched to a 
"tracking** view of the cue data, presenting the viewer with only the cue data which has changed value from 
25 the previous cue (or from any arbitrary cue). 

The rows of any spreadsheet can be sorted in a number of ways. The rows of the "luminaire" and 
"cue** windows, comprised of luminaires or dimmer channels, can be sorted by their channel number. 
Alternatively, the rows can be arranged so that all of the channels of similar luminaire types ( \/L2B^ , 
, VL4^" . etc.) can be grouped together, and then can be secondarily sorted by channel number. 
30 . The row headers of the "model window** contain the symbolic names of all of the objects in the model. 
This spreadsheet can be sorted alphabetically by object name for non*luminaire objects and by channel 
number for the luminaires. Alternatively, the rows can be grouped by object type (e.g.. target, luminaire. 
etc.) and secondarily sorted by name. 

The program design also permits the programmer to establish spreadsheet templates that may be used 
35 to reformat a spreadsheet or utilize previously established spreadsheet formats. A programmer can create a 
spreadsheet template by placing a spreadsheet window in the front window on display screen 24 and 
executing a menu command to create a template of that spreadsheet's format. The menu command invokes 
a dialogue message that allows the programmer to attach a symbolic name to the template. To store a 
: template, a document is created in memory and written to disk that contains the template name, the 
40 spreadsheet type (model, luminaire. or cue window), the object types displayed in the spreadsheet (row 
headings), their associated attributes (column headings), and the order of these attributes. 

Once the programmer has established a desired template he is able to call up a spreadsheet to the 
front window of display 24 and execute a menu command that is available to reformat the spreadsheet 
according to that template (or another if he wishes). Upon execution of the menu command, the 
45 programmer is presented with a dialogue message containing a listing of all of the available spreadsheet 
templates that are appropriate for that type of spreadsheet (e.g.. model, luminaire, or cue window). A 
selection can then be made. 

The programmer has the means to open and close any of the spreadsheet windows. Additionally, when 
the information contained in a spreadsheet view exceeds the available display area, the scroll bars on 
50 display 24 are enabled that allow the programmer to show portions of the document not currently displayed. 
Objects can be created, modified and deleted within the spreadsheet view of the model. Object 
attributes can be changed in a spreadsheet view with the same menu commands and dialogues used in the 
graphical view or by selecting one or more cells and entering a new value at the keyboard. As in other 
modes, new values entered from the keyt>oard are automatically checked by the system for errors. Almost 
55 all of the attributes of the modeled objects can t>e modified in this manner. 

The objects that the programmer wishes to alter in the spreadsheet view must be activated or selected 
before they can be operated upon. An object can be selected in a spreadsheet window by clicking on the 
appropriate row header describing the object. A group of objects can be selected in the spreadsheet view 
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When initially building the model, the progrannmer can be presented with a menu or listing of building 
blocks or symbolic representations for all of the elements that would likely be placed in the lighting systenn 
model. This building block menu, similar to a legend or key, is presented as a separate screen, a pull-down 
menu, or a window on a portion of the screen. As shown in Figure 3, when presented with this menu of 

5 building block altematives, the programmer can designate his building block choice to computer 20 by 
manipulating mouse 28 so cursor 34 points to his selection from among alternatives 66 a-g. Selection of this 
building block is by depressing key or button 29 provided on mouse 28. The selected "icon" will be 
distinguished from non-selected items. If a pull-down menu system is utilized to access the building block 
menu, the programmer must first access the pull-down menu by selecting the menu from menu bar 38. In 

to the preferred embodiment, the building block menu (or "objects palette") is accessed by selecting menu 
44d in Fig. 2d. Thereafter the programmer "drags" the cursor down to highlight the "show objects palette" 
option. The building block menu then appears in a window on the screen. 

Once the programmer has accessed the list of building blocks he can begin selecting the desired 
objects to be included in the model. A typical legend menu 62 is shown in window 58 of Rg. 3. The legend 

»•» sceen Of menu 62 comprises symbolic representations 66 a-g or "icons" that are small pictures that 
repcesem ava lable elements that can be used in a typical lighting system. The modelling system can be 
programmc-d vwiih a directory of the symbolic representations of elements that are common in lighting 
systems and ihc surrounding environments, this directory being stored in computer 20. The directory is 
accocsjbic to the user so that it can be updated by adding or deleting elements as necessary. 

?0' Upon the soioction of a building block element by the programmer, a record is created in the undeffying 
data base m \t>e storage means of computer 20 to store all of the necessary information for that object. 
Preferably, the records are broken down into fields for each attribute of the object that is to be stored. As 
will be discussed t>elow. when the programmer selects an icon the modelling system will know what that 
icon IS. and <t can create a record in the memory specifically designed for that type of object. The created 

25 record will hav/e fields for every attribute that must be known in order to completely model and program 
each obiect. The record creation will be discussed with respect to each building block element below. The 
information that is created in the memory records during the creation of the model helps to facilitate the cue 
writing process. 

30 LIGHTING INSTRUMENTS 

Icons 66 a-d in the building block menu of Fig. 3 are symbolic representations of various lighting 
instruments that can be utilized in a lighting system. In a preferred embodiment of the invention, each type 
of unique lighting instrument is assigned its own symbolic representation. In the legend menu 62 of Fig. 3. 

35 each of the elements 66 a-d represent different lighting instruments. 

For example, icon 66a represents a standard conventional light that is focussed by hand and whose 
intensity is controlled by an external dimmer. If the programmer clicks on icon 66a to select a conventional 
light for inclusion in the model, a record will be created in the underlying data base with appropriate fields 
and the programmer will be prompted to enter the information that is necessary to define the conventional 

40 light. Upon selection of a conventional light, the programmer is prompted to enter the channel number 
identifying the light, the symt)olic name of the support from which the conventional light will hang and the 
positioning of the light relative to its support. 

This information is stored in the appropriate fields of the record associated with this modelled object. 
Since conventional lights only offer variable intensity control, a field is created in the record to store the 

45 intensity value. The record created upon selection of a conventional light can also include such fields as 
channel number, object type, supporting object, translation (x.y.z translation with respect to its support), 
rotation (x.y.z rotation with respect to its support), focus (pan and tilt values that will not change with the 
recall of cues), color (value won't change with the recall of cues) and intensity (representation of the value of 
the control signal (0 • 100%) that is sent to the dimmer device to which the luminaire is connected). All of 

50 the fields except for intensity are generally defined once the programmer has included and defined the light 
in the model. 

Automated lights can also be assigned unique symbolic representations such as the icons 66 b-d. Fig. 
3. As in the case of a conventional light, the selection of an icon 66b - 66d (representing an automated light) 
establishes a record in computer storage with the appropriate fields and the programmer can be prompted 
55 to enter channel number, support, and position relative to the support associated with the light for entry into 
the associated fields. 

In one embodiment, icon 66b represents a Vari-Ute "VL2B^" model: 66c represents a Vari-Lite 
"VL3™" model, and 66d represents a Vari-Lite "VL4~" model. Since the modelling system is pro- 
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the lighting system. Upon selection of a tMjildIng block element by clicking on it the programmer is 
prompted to supply the information needed to define the building block element. 

Alternatively, the programmer can select a building block by entering an alphanumeric character on 
keyboard 30 that is associated with that element. 

5 As information is retrieved from the programmer It is placed In the appropriate fields of the record 
associated with the selected model object. 

- An efficient method of prompting the programmer to retrieve necessary definitional information is by 
means of "dialogue boxes". Typical dialogue boxes are shown in Figs. 6-8. The dialogue box is a window 
that can be used to contain text or symbolic representations. 

10 Once the programmer selects a building block element from legend menu 62, the modelling system will 
recognize the type of object selected (e.g., truss, target, VL4^ , etc.) and can retrieve from memory any 
previously-stored characteristics or other information describing that object. This minimizes the information 
that must be entered by the programmer and maximizes the operating efficiency. 

75 2. Assigning a Symbolic Name 

The programmer can also use the dialogue box or other data entry means such as keyboard 30 to 
attach a symbolic name to the graphical object that he has selected. During the programming process the 
symbolic names provide the programmer with an easy means for identifying particular targets and elements 
20 within the lighting system. For changing a defined symbolic name, the programmer can solect icon 1 35 of 
Figs. 7-9. causing a dialogue lx>x to be presented on the screen. The dialogue box will show the 
programmer the symbolic name that is presently associated with the selected object and allow it to be 
updated. The "name" icon 135 can be accessed by means of a pull-down menu or by a palette of tools 
presented in a window on a portion of the display as shown in Rg. 9. 

3. Defining Dimensions 

After selection of a building block, the programmer is prompted to enter its dimensions. In the preferred 
embodiment, the dimensions of the lighting instrument building blocks shown as 66 a - d of Fig. 3 are pre- 
30 programmed and the programmer will not be prompted for their dimensions. However, when the program- 
mer selects any of building block icons 66 e - g he will be prompted for the dimensions of the selected 
object. The entered information is placed in the appropriate fields in the record created for the model 
object. 

In the preferred embodiment, the programmer can update previously defined dimensions of a selected 
35 model object by selecting the "dimension icon" 137 of Fig. 9. Upon such selection, a dialogue box will be 
presented with the dimensions of the selected object. The programmer will be able to update the presented 
information. 

4. Defining Supporting Object 

40 

In the preferred embodiment, the programmer is provided with a "support" icon 139 for updating a 
selected graphical object. Upon selecting a graphical object and clicking on the "support" icon 139. a 
dialogue box is presented containing the symbolic name of the object that supports the selected pbject. 
Thereafter, the programmer will be able to change the supporting object. The "support" icon 139 can be 
45 accessed by means of a pull-down menu or from a palette of tools 130 presented in a window on a portion 
of the screen, 

5. Defining Positional Information 

50 In addition to identifying and defining the characteristics for the building block object to be included in 
the model, the programmer also defines the position of the object within the model. After the programmer 
has entered ail of the definitional information that has been requested, the pbject is initially inserted in the 
model in a default location corresponding to the center of the space that supports the object. For example, 
if the object is a target (e.g. a performer) supported by the stage, the target is placed at the center point of 

55 the stage and at zero rotation with respect to the stage. Thus, the graphical object initially has a translation 
of (0,0.0) and a rotation of (0.0,0) with respect to its support. 

The programmer changes the position of the selected object by clicking on its image, moving the 
objects outline with mouse 28 to the location where the programmer would like to position the object. He 
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Rotation alsout the y axis is given by: 
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And finally, a rotation of angle 0 about the z coordinate axis is represented by: 
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By utilizing a concatenation process, any number of successive transformations can be represented by 
. a single transformation matrix. If a first translation is represented by matrix Ti . tfien a rotation about the x 
35 axis represented by matrix Rx, and finally another translation represented by matrix T2. the coricatenated 
transformation to represent this sequence that places the new coordinates at (x\ y\ 2') is: [x* y* z' 1] = [x y 
z 1] (Tt ' Rm •T2), The order of operations must be maintained when the transformation matrices are cross 
multiplied together. 

Cross multiplying by the inverse matrix M' of a matrix M performs the symmetrically opposite 
40 transformation. The result of this operation is to undo the effect of the transformation with the matrix M. 

Illustration 

To illustrate the addition of a building block to the model, the selection of the stage's building block 
45 element for inclusion in the model and the definition of its necessary characteristic information is discussed 
with respect to the preferred embodiment. The stage is generally one of the first elements to be defined 
and placed in the model. The stage is often the support for numerous objects in the model so many other 
elements are often defined with respect to the stage location. Referring now to Fig. 3. and as discussed in 
general above, the programmer selects the symbolic representation of the stage icon 66e by manipulating 
5a cursor 34. Upon selection of stage icon 66e. the processing means of computer 20 recognizes that the 
programmer has selected the symbolic representation for the stage or related platforms. The appropriate 
record and corresponding fields (as discussed above) is established in the data base stored in computer 20. 
The programmer's selection of the stage element from the legend menu triggers a request, generally by 
means of a dialogue t)Ox (as shown in Fig. 8), to attach a symbolic name such as "stage" to the object. The 
55 symbolic name facilitates later programming, and allows the programmer to identify the stage when using it 
as a support for other objects. 

The processing means of computer 20 recognizes that the programmer has selected icon 66e. The 
selection of this icon invokes a dialogue message such as that shown in Figure 7, that retrieves the length. 
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and drags the cursor to include all of the desired lights within the highlighting box 50. The ability to select a 
predefined group of lights is sinf>ilar to the "Group Select" option that is a common function of the Vari-Lite 
control consoles. This feature simplifies the processes performed by the programmer when he wishes to 
assign the same value for a selected attribute to a group of lights, for example directing a number of lights 
5 to the same target. Thereafter, the programmer can assign a symbolic name to the group of lights just 
selected. 

Defining Target Parameters (Pan and Tilt) 

JO The programmer moves the lights to focus on a target by controlling the focus (or pan and tilt) 
parameter of the lights. The programmer can establish the pan and tilt values of any light in either a direct 
or indirect manner. 

The information recorded in the model has established the position of every element within free space. 
This information allows the calculation of the pan and tilt values required to point a particular light at a 
15 certain target. The pan and tilt values can be calculated by retrieving the location of the particular light and 
the particular target in free space. This has an advantage over methods of programming employed with the 
actual lighting system where the pan and tilt values have to be manually adjusted until the light is focused 
correctly on its target. 

The programmer can specify that the pan and tilt values of any light shall be such that the light is 
20 focused on a defined target object. Using this "parametric" definition of the pan and tilt values which 
associates the light or lights with a particular target, the modelling system can compute the appropriate 
values. To focus the lights in this manner, the programmer indicates the symbolic name of the appropriate 
target to the computer. The associated target for a light can be retrieved by the programmer by using the 
dialogue box query of the target's symbolic name. In this embodiment, the programmer indicates to the 
25 modelling system the target that the light should be focussed on. Thereafter, the required pan and tilt values 
are computed. If the resulting tilt is impossible, the programmer is notified by the modelling system. 

If a light is focussed by associating a target, the symbolic name of the target and the calculated pan 
and tilt values can be stored in the light's record. If the target is later moved in the model, the pan and tilt 
values will be correspondingly changed and updated to maintain focus on the target. Again, if the resulting 
30 tilt is impossible, the programmer is notified. When the cue data is transferred to the control console of the 
lighting system, the pan and tilt values for lights focussed on targets will be transferred as absolute pan and 
tilt values. 

A second method defines the pan and tilt values for the selected lights by entering "absolute*" 
numerical values. This is done by selecting the light or lights to be defined and then responding to a 
35 dialogue box query to enter the pan and tilt values. 

A third method of defining pan and tilt values for a light is by "preset focus**. This method, as 
implemented in the Vari-Lite console, focusses the lights to their targets by a dereferenced or indirect 
specification. The programmer selects an arbitrary number of lights, assigns a target to them or enters 
absolute numerical values and then stores this configuration as a preset focus by attaching an alphanumeric 
40 symbolic name to it which serves to identify it. 

The preset focus position of all presently activated lights can thus be stored in a file and retrieved at 
any time by entering the identifying name. This retrieves for each light the pan and tilt values required to 
focus the light on the desired position. 

When a programmer fixes the pan and tilt values for a cue by means of a preset focus, the symbolic 
45 name of the preset focus is stored in the cue. The file defining each preset focus is also transferred to the 
control console. When the data is transferred, the pan and tilt values defined in this manner will be identified 
by the associated preset focus symbolic name. When a cue using preset focus is executed in a light, the 
light retrieves the proper pan ana tilt value by referring to its preset focus record. Prompts for preset 
focuses can be presented to the programmer as a graphical duplicate of the preset focus panel on the Vari- 
50 Lite console. 

A lighting designer uses several different combinations of beam spread and tilt angle to light a 
performer standing on stage. A 'head shot' uses a narrow beam of light which only illuminates the performer 
from the neck up to the top of the head. A 'head-and-shoulders shot' is similarly from the shoulders up. A 
waist shot' illuminates the performer from the waist up. A 'full-tDOdy shot' illuminates the performer from the 
55 feet to head. For any given luminaire illuminating a performer, the tilt value and beam size (beam angle) will 
be different for each of these 'shots*. 

By embedding knowledge of the proportional sizes of the various parts of the human body in the model, 
the system can calculate the pan/tilt and beam size for each luminaire to achieve a head shot, waist shot. 
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The flow chart in Fig. 16 shows a method for determining which pair of azimuth and elevation values will 
point the light to the target with minimum yoke movement. The azimuth and elevation (calculated in radians) 
are converted into degrees in step 192. Additionally. It is necessary to determine the corresponding pan- 
azimuth value (panaz) associated with the present pan setting (pannow) 192. "Panaz" is used in comparing 
5 the two pan-azimuths which point to the target and in determining which is preferred. 

In step 194 the two possible pan-azimuths that point at the target are obtained by adding 90* to the 
azimuth (pazi) and subtracting 90* from the azimuth (paz2). The 90* is added or subtracted from the 
calculated azimuth value so that the plane of tilt rotation will pass through the target. Since a pan-azimuth of 
0* is defined in Fig. 12 to be pointing along the x axis, a pan-azimuth of 0* puts the tilt plane in the plane 
. 10 of the y-z axes. In this position, the lamp could point to an azimuth of 90* or 270*. Thus, in order to 
produce a pan-azimuth from an azimuth, 90* must be added to or subtracted from the desired azimuth. 

Since the range of valid pan-azimuths is limited to 0* through 360*. steps 196 - 202 guarantee that 
-pazi" and "paz2'' are maintained in this range (modulo 360 •). If pazi is greater than 360* then 360* will 
be subtracted from the value (step 198). For example, a pan«azimuth of 400* is beyond the range of the 
IS lamp so the value is reduced by 360* to an equivalent pan-azimuth of 40* . Similarly, if paz2 is less than 
0* then 360* will be added to it. to keep the pan-azimuth in range (step 202). 

As a result of pan stop 150. pan-azimuths of 0* and 360* represent different positions of the yoke, 
each being on opposite sides of pan stop 1 50. In steps 204 through 220. it is determined whether the two 
possible pan-azimuths (pazi and paz2) are set to either 0* or 360*. tf pazi is equal to 360* and panaz 
20 (the present pan-azimuth setting) is less than -ISO* (step 216) then pazi should be set to 0* (step 210) in 
. order to minimize the rotation of the lamp. However, if panaz is equal to 180 * (step 208) then each direction 
of rotation is the same, and a "tie-breaker" should determine whether 0* or 360* is used (step 212). This 
tie-breaker can be under user control. Steps 21 4 through 220 show the steps for analyzing paz2. After these 
steps have been performed, there are two possible solutions for pan-azimuth that are 180* apart. These two 
25 values are the output of the flow chart shown in Fig. 16. 

The flow chart of Fig. 17 (see also Figs. 18a, b and c) determines which of the two solutions should t>e 
utilized. Step 230 determines the delta angular distance that must be traveled by the lamp in moving from 
the present setting to the new setting for each of the two pan-azimuth values (resulting in deltal and 
delta2). In step 232. it is determined whether both paths travel the same angular distance. If they do. then 
30 the tie-breaker determines which pan-azimuth will be used (step 234). 

However, if the paths are not the same, then a determination is made as to which value represents the 
shortest angular distance (which is the smaller of deltal and delta2). If the angular distance offered by the 
first value (pazi) is smaller than the angular distance offered by the second (paz2). then the algorithm 
proceeds to the branch of the flow chart with steps 240, 246 and 248. Step 240 determines whether you 
35 can get to the new pan-azimuth value from the previous pan-azimuth value without traveling through pan 
stop 150. If so. then the first pan-azimuth value (pazi) is selected and converted to a pan value. The 
corresponding tilt value is chosen based on the "tilt sense" value, where: 

tilt elevation ' tilt sense, (step 250). 

40 

If Step 240 determines that the light cannot travel from the previous pan-azimuth value to the new pan- 
azimuth value without going through the pan stop 1 50, then the longer distance (paz2) should be chosen. 
Steps 238, 242 and 244 proceed from step 236 when the angular distance to be traveled is shorter for the 
paz2 value. These steps are evaluated in the same manner as steps 240. 246 and 248. 
45 Since tilt values are limited to the range of '••135* and -135*. if an impossible tilt value results then 
there will be no solution and an error condition will arise. 

Example 

50 The pan and tilt computation is discussed below with respect to the position of a target in a lamp's 
coordinate system. In order to illustrate, a target having coordinates of (20.20.45) in the lamp's coordinate 
system is discussed. Proceeding initially to the steps shown in Fig. 14. the x and y coordinates of the target 
are both positive (condition of Step 160). therefore the calculation results in an Azimuth equal to the inverse 
tangent (arctan) of (20/20) or the arctan of 1. This results in an azimuth value of vf4 radians (or 45 degrees). 

55 Thereafter, the elevation is calculated according to the method shown in Fig. 15. Since the error 
condition of Step 180 is not satisfied, the following elevation computation is performed in Step 184: 

Elevation = Arccos (45/(20^ + 20^ + 4S^y% 
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lighting system (such as color, beam size, intensity, edge and gobo) in a number of ways. One alternative is 
to define the parameters in an "absolute" manner. As an illustration, if the programmer wishes to define the 
intensity of the lights in an ''absolute*' manner, he can specify that all of the selected lights should have an 
absolute intensity value, for example an intensity of 65%. Parameter data that has teen defined in an 
5 "absolute" manner will not be automatically updated as alterations are made in the model. 

Alternatively, the programmer can define these parameters in a "parametric" manner, which allows the 

. programmer^ to assign parameter_values with respect to a particular target. To Illustrate, if the programmer 

defines the intensity in a "parametric" manner, he specifies that all of the lights which are focused on a 
particular target or are in a particular color or are mounted on a particular truss^ shall have a particular 
w intensity, for example an intensity of 65%. The target or color or truss may be chosen by utilizing a 
dialogue box to enter the symbolic name that identifies it or by selecting it with the input device as 
discussed above. 

In another variation, the programmer specifies that all of the lights focused on a particular target should 
t^e adjusted to produce a desired intensity at the target. The system calculates the required intensity for 
IS each light so that for the combined effect of all the lights focused on the target achieves the desired lighting 
level. 

Defining Color 

20 When the programmer is specifying the color for a particular light or group of lights, he may select the 
color in a number of ways. Once the programmer has selected a light to be defined as part of the model, 
the particular type of light that has been selected is known. Correspondingly, the color palette appropriate 
for that type of lighting instrument can be presented to the programmer in a dialogue box. The programmer 
can use the palette to select the color. In this manner, the programmer can review the available colors and 

35 select the desired one. The color palette can be presented in a familiar format such as by the chromaticity 
triangle. Alternatively, the programmer may wish to enter an alphanumeric name that has been associated 
with a color he desires. As another possibility, the programmer may define color In an absolute manner by 
directly controlling the positions of the color filtration elements in the lighting unit. This is obtained by 
defining the position of the color wheels (for example in a VL2B^). or by defining the angles for each of 

30 the three color filters (magenta, amber, blue) of a lighting unit such as in a VL4^'' . 

In a preferred ernbodiment of the invention, the programmer is able to assign the color of a lighting 
instrument by establishing "preset colors", similar to the control offered by the Van-Lite console. Typically 
the color produced by a lighting instrument can be defined with "standard" colors (assigned by the 
manufacturer) as well as "custom" and "open" colors (assigned by the programmer). When the color is 

35 defined by using "custom", the preset color identifier is stored in the cue. The programmer defines 
"custom** colors indirectly, by means of dereferenced colors. The color that will be recalled when the cue is 
initiated is the color that is programmed Into the "custom" palette at the time when the preset color is 
stored. When the color of lighting instruments is defined by means of "open" colors, they will be assigned 
an absolute color. 

40 The color of a selected light can be specified by a prompt which duplicates the Preset Color controls of 
a Vari'Ute control console. In that console, the action of pressing a preset color button on a console sets 
the currently selected lights to the color assigned to that preset color. 

Gobo Selection 

45 

Similarly, if the lighting instrument being defined achieves beam modification by means of a gobo. the 
data base can maintain tables of the available golx) selections for each lighting instrument being used and 
the gotx) selected. When selecting the gobo to be used to project a desired beam configuration, the 
programmer can be presented with a graphical representation containing all of the possibilities. The 
50 programmer then merely selects the gobo that he would like to use to achieve the desired effect from the 
alternatives presented. Alternatively, the programmer can specify his gobo selection by indicating the stop 
position of the gobo wheel. 

When defining other beam characteristics, such as beam size, intensity, and edge the programmer may 
specify these values by entering the desired values in a dialogue box. 

55 

STORING CUE DATA 

Once the programmer has obtained the desired lighting effect for a particular cue by manipulating the 
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entry, or using the spreadsheet mode as discussed above. As the programmer modifies the model, e.g.. as 
he moves an object to a new location on the display screen, the new information is reflected by a change of 
values in the underlying corresponding data base. 

Any needed update to the model can be easily executed in order to incorporate new information into 
5 the model to accurately reflect the actual lighting system and stage environment. 

UPDATE OF PREVIOUSLY WRITTEN CUE INFORMATION 

Furthermore, the parameter data stored as cues may need to be updated if the sequence of events in 
•0 the performance has been changed, or the location of targets in certain cues is modified. As discussed 
above, the programmer can update cue data by retrieving the cue from memory by indicating the cue to be 
reineved and clicking on the "RCL" icon shown in window 70 of Fig. 19. Thereafter, the previously stored 
lighting effect as a function of the stored parameters can be displayed on the screen and updated. The 
Cfogrammer can alter any parameter that does not conform to the actual situation. If a target location for the 
cue has been relocated, the programmer can select the target as discussed alx>ve and "drag" it to its new 
io:ai.on As an alternative the programmer may also update any target information by interacting with the 
m.>jciiing system by means of a dialogue box. 

DATA TRANSFER 

As suggested m Figure 1 . the cue data that is written by the programming system to define a lighting 
effect IS translated mto data that may be transferred directly to a lighting control console or to local lighting 
instruments. (In the latter case, the modelling computer is serving as the console.) The syntax of the data 
should be mutually interpretable by the modelling and programming system disclosed herein and by the 

25 conventional control consoles and lighting instruments. In addition to being machine readable, it is 
preferrable that the data fonmat be human readable as well. A readable textual representation of the data 
makes the debugging process easier. The modelling and programming tool, and the actual lighting system 
shouid be able to read and write in this data format to facilitate bidirectional communication. Additionally, 
error handling capabilities allow the system to be fault tolerant. 

30 The data format also provides a uniform method for storing all of the cue information that is necessary 
for each lamp. The file can be arranged in a manner that lists the name and location of each lamp, and 
stores the parameter data for every cue in the show. 

Using the bidirectionality facilitated by this data format, the user can transfer data which has been 
created or modified in the control console back into the modelling system for subsequent display and 

35 further modification. 

REAL-TIME RENDERING 

The data that has been stored by the modelling system may be processed by a rendering device in 
40 order to generate photo-realistic images that represent the stored data. This sen^ice is provided for example 
by the use of a RenderMan program. See "The RenderMan Interface" published by Pixar. 3240 Kerner 
Blvd., San Rafael. OA 94901. This document details the services available from a RenderMan rendering 
program. 

These images can be utilized to depict what the lighting effect is going to look like. Further, utilizing 
45 computer animation techniques to project a continuous sequence of cues at speeds which approach real- 
time, the viewer can observe chases and the dynamics of the lighting show. The quality of the simulation is 
a function of the sophistication of the hardware and software platforms that are selected to do the rendering. 
The sophistication of the image that is available to an average user will improve as the costs and 
processing power of available systems improve. The technology is moving closer to lower cost systems 
50 with excellent simulation capabilities. Ultimately these rendering devices can be used by lighting designers 
to present a client with a completely simulated performance complete with all of the lighting effects. 

Using speaker-independent voice recognition systems with large vocabularies such as those sold by 
Kurzweil Applied Intelligence of Waltham. MA, the modelling system can provide spoken access to any of 
its capabilities. 

55 

VIRTUAL CONSOLE / VIRTUAL REALITY 

With equipment developed by VPL. 656 Bair Island Road. Redwood City, CA, 94063. the 2-D display 
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for simultaneously generating and displaying views of said lighting scenes from different perspectives. 

6. A system as defined in claim 1 in which said means for computing said representations includes means 
for displaying the contributions of the site, light location and light parameter values to the aggregate 

5 lighting scene. 

7. A system as defined in claim 1 including means for computing pan and tilt values as a function of 
lighting instrument location and target position. 

ro & A system as defined in claim 1 including means for organizing the components of said site parameters 
on a hierarchical basis. 

9. A system as defined in claim 1 including means for generating menus, dialog boxes and icons to 
facilitate entering of said data. 

rs 

10. The system according to claim 1 in which said representations constitute cues which can be stored and 
recalled at wlil. 

11. A system according to claim 1 in which lighting parameters can be specified in terms of target 

20 positions. 

12. A system according to claim 1 in which said lighting targets include representations of performers and 
wherein lighting parameter data can be defined and processed to illuminate portions of said performer. 

25 13. A system according to claim 1 including means for representing target volume as an object in the 
system and wherein said volume can be moved and sized, producing corresponding adjustments in 
associated lighting parameters. 

14. A system according to claim 1 In which said means for entering site data includes means for 
30 generating a plurality of orthogonal views on said monitor to display all the positional coordinates of 

objects in said site. 

15. A system according to claim 1 in which the output of said computing system is linked to said console 
for the exchange of lighting parameters. 

35 

16. A system according to claim 1 in which said modelling system includes means for displaying model 
data in a variety of selectable formats. 

17. A system according to claim 1 in which said modelling system includes means for receiving from said 
40 console, data describing actual productions for review and modification by said modelling system. 

18. A system according to claim 1 in which said modelling system includes means for controlling said 
lighting instruments from said modelling system. 

45 19. A system according to claim 1 in which said modelling system includes means for specifying the 
relation t)etween model objects. 

20. A system according to claim 1 in which said modelling system includes means for simulating dynamic 
aspects of said lighting scenes. 

50 

21. A method for modelling a lighting production including the production site and the lighting designs 
produced by the lighting console and lighting instruments, said modelling method employing a 
computing system having a graphic display program, data entry means, data processing means 
including a graphic generating program, and a monitor; said method comprising the steps of 

55 (1) entering data into said computing system describing relevant characteristics of said lighting site 

including lighting targets; 

(2) entering data into said computing system identifying the lighting instruments to be involved in a 
scene: 
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37. A method according to claim 21 including receiving from said console, data describing actual 
productions for review and nnodification by said modelling system. 

38. A method according to claim 21 including controlling said lighting instruments from said modelling 
5 system 

39. A method -according to claim-21 including specifying the relation between model objects; 

40. A method according to claim 21 including simulating dynamic aspects of said lighting scenes. 
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